Search Results: "kitterman"

4 May 2015

Lunar: Reproducible builds: first week in Stretch cycle

Debian Jessie has been released on April 25th, 2015. This has opened the Stretch development cycle. Reactions to the idea of making Debian build reproducibly have been pretty enthusiastic. As the pace is now likely to be even faster, let's see if we can keep everyone up-to-date on the developments. Before the release of Jessie The story goes back a long way but a formal announcement to the project has only been sent in February 2015. Since then, too much work has happened to make a complete report, but to give some highlights: Lunar did a pretty improvised lightning talk during the Mini-DebConf in Lyon. This past week It seems changes were pilling behind the curtains given the amount of activity that happened in just one week. Toolchain fixes We also rebased the experimental version of debhelper twice to merge the latest set of changes. Lunar submitted a patch to add a -creation-date to genisoimage. Reiner Herrmann opened #783938 to request making -notimestamp the default behavior for javadoc. Juan Picca submitted a patch to add a --use-date flag to texi2html. Packages fixed The following packages became reproducible due to changes of their build dependencies: apport, batctl, cil, commons-math3, devscripts, disruptor, ehcache, ftphs, gtk2hs-buildtools, haskell-abstract-deque, haskell-abstract-par, haskell-acid-state, haskell-adjunctions, haskell-aeson, haskell-aeson-pretty, haskell-alut, haskell-ansi-terminal, haskell-async, haskell-attoparsec, haskell-augeas, haskell-auto-update, haskell-binary-conduit, haskell-hscurses, jsch, ledgersmb, libapache2-mod-auth-mellon, libarchive-tar-wrapper-perl, libbusiness-onlinepayment-payflowpro-perl, libcapture-tiny-perl, libchi-perl, libcommons-codec-java, libconfig-model-itself-perl, libconfig-model-tester-perl, libcpan-perl-releases-perl, libcrypt-unixcrypt-perl, libdatetime-timezone-perl, libdbd-firebird-perl, libdbix-class-resultset-recursiveupdate-perl, libdbix-profile-perl, libdevel-cover-perl, libdevel-ptkdb-perl, libfile-tail-perl, libfinance-quote-perl, libformat-human-bytes-perl, libgtk2-perl, libhibernate-validator-java, libimage-exiftool-perl, libjson-perl, liblinux-prctl-perl, liblog-any-perl, libmail-imapclient-perl, libmocked-perl, libmodule-build-xsutil-perl, libmodule-extractuse-perl, libmodule-signature-perl, libmoosex-simpleconfig-perl, libmoox-handlesvia-perl, libnet-frame-layer-ipv6-perl, libnet-openssh-perl, libnumber-format-perl, libobject-id-perl, libpackage-pkg-perl, libpdf-fdf-simple-perl, libpod-webserver-perl, libpoe-component-pubsub-perl, libregexp-grammars-perl, libreply-perl, libscalar-defer-perl, libsereal-encoder-perl, libspreadsheet-read-perl, libspring-java, libsql-abstract-more-perl, libsvn-class-perl, libtemplate-plugin-gravatar-perl, libterm-progressbar-perl, libterm-shellui-perl, libtest-dir-perl, libtest-log4perl-perl, libtext-context-eitherside-perl, libtime-warp-perl, libtree-simple-perl, libwww-shorten-simple-perl, libwx-perl-processstream-perl, libxml-filter-xslt-perl, libxml-writer-string-perl, libyaml-tiny-perl, mupen64plus-core, nmap, openssl, pkg-perl-tools, quodlibet, r-cran-rjags, r-cran-rjson, r-cran-sn, r-cran-statmod, ruby-nokogiri, sezpoz, skksearch, slurm-llnl, stellarium. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which did not make their way to the archive yet: Improvements to reproducible.debian.net Mattia Rizzolo has been working on compressing logs using gzip to save disk space. The web server would uncompress them on-the-fly for clients which does not accept gzip content. Mattia Rizzolo worked on a new page listing various breakage: missing or bad debbindiff output, missing build logs, unavailable build dependencies. Holger Levsen added a new execution environment to run debbindiff using dependencies from testing. This is required for packages built with GHC as the compiler only understands interfaces built by the same version. debbindiff development Version 17 has been uploaded to unstable. It now supports comparing ISO9660 images, dictzip files and should compare identical files much faster. Documentation update Various small updates and fixes to the pages about PDF produced by LaTeX, DVI produced by LaTeX, static libraries, Javadoc, PE binaries, and Epydoc. Package reviews Known issues have been tagged when known to be deterministic as some might unfortunately not show up on every single build. For example, two new issues have been identified by building with one timezone in April and one in May. RD and help2man add current month and year to the documentation they are producing. 1162 packages have been removed and 774 have been added in the past week. Most of them are the work of proper automated investigation done by Chris West. Summer of code Finally, we learned that both akira and Dhole were accepted for this Google Summer of Code. Let's welcome them! They have until May 25th before coding officialy begins. Now is the good time to help them feel more comfortable by sharing all these little bits of knowledge on how Debian works.

27 April 2015

Scott Kitterman: Enabling DNSSEC Support For OpenDKIM

If you are using DNSSEC you can now use it to verify DKIM keys with opendkim. This does require a bit of configuration. Opendkim uses unbound for DNSSEC support. You have to: ResolverConfiguration /etc/unbound/unbound.conf Once that s done, restart opendkim and your DKIM key queries are DNSSEC protected (you can verify this in your mail logs since opendkim annotates unprotected keys when it logs). Note: This should also apply to Ubuntu 14.04, 14.10, and 15.04. Update: In Wheezy (and Squeeze, at least the version in backports, I didn t check the release version) and Ubuntu 10.04 (similarly with backports) this was possible too. The opendkim.conf parameter was called UnboundConfigFile. You may have to update your local configuration to use the new name when you upgrade.

25 November 2014

Scott Kitterman: On being excellent to each other

There has been a lot of discussion recently where there is strong disagreement, even about how to discuss the disagreement. Here s a few thoughts on the matter. The thing I personally find the most annoying is when someone thinks what someone else says is inappropriate and says so, it seems like the inevitable response is to scream censorship. When people do that, I m pretty sure they don t know what the word censorship actually means. Debian/Ubuntu/Insert Project Name Here resources are not public spaces and no government is telling people what they can and can t say. When you engage in speech and people respond to that speech, even if you don t feel all warm and fuzzy after reading the response, it s not censorship. It s called discussion. When someone calls out speech that they think is inappropriate, the proper response is not to blame a Code of Conduct or some other set of rules. Projects that have a code, also have a process for dealing with claims the code has been violated. Unless someone invokes that process (which almost never happens), the code is irrelevant. What s relevant is that someone is having a problem with what or how you are saying something and are in some way hurt by it. Let s focus on that. The rules are irrelevant, what matters is working together in a collegial way. I really don t think project members actively want other project members to feel bad/unsafe, but it s hard to get outside ones own defensive reaction to being called out. So please pay less attention to how you re feeling about things and try to see things from the other side. If we can all do a bit more of that, then things can be better for all of us. Final note: If you ve gotten this far and thought Oh, that other person is doing this to me , I have news for you it s not just them.

30 August 2013

Scott Kitterman: skitterman

This hit my Washington Post Top Stories feed tonight: The case against software patents Maybe the word is getting out

20 July 2013

Luke Faraone: Joining the Debian FTPTeam

I'm pleased to say that I have joined the Debian FTPTeam as of the Friday before last. See Joerg Jaspert's announcement on debian-devel-announce.

The FTPTeam is responsible for maintaining the Debian software archive, and ensures that new software in Debian is high-quality and compliant with our policies.

As an "ftpassistant", I (along with Paul, Scott, Gergely, and others) will be helping to process the NEW queue, which is currently at a whopping 297 packages. Here's hoping we'll be able to get that number down over the coming weeks!

16 May 2013

Scott Kitterman: New ipaddress module in python3.3

Back in 2010 I packaged Google s ipaddr module because I needed a light weight IP address manipulation library that supported both IPv4 and IPv6 and (at the time) python-subnettree was IPv4 only. Well, ipaddr is all grown up now and included in python3.3 as the ipaddress manipulation module in the standard library. You can find details, as well as some description of the differences, in PEP 3144. I just converted one package that I m upstream for to use either ipaddr (for python2.6/2.7/3.2) or ipaddress instead of some custom code. It turned out to be pretty easy to make it work with either. Other than the name, the only difference I ran into was the removal of the common, generic IPAddress and IPNetwork functions that are replaced by ip_address and ip_network.
-import ipaddr
+try:
+ import ipaddress
+except ImportError:
+ import ipaddr as ipaddress

- address = ipaddr.IPAddress(ip)
- if isinstance(address, ipaddr.IPv4Address):
+ try:
+ address = ipaddress.ip_address(ip)
+ except AttributeError:
+ address = ipaddress.IPAddress(ip)
+ if isinstance(address, ipaddress.IPv4Address):
Currently, python3-ipaddr has no reverse-dependencies in the archive (python-ipaddr does). Once python3.2 is dropped from Jessie, I think I ll drop the python3-ipaddr binary on the assumption people newly coding for python3.3 should use ipaddress. The python-ipaddr module will stick around for use with python2.7.

16 February 2013

Luca Falavigna: The DPL Game

Playing the DPL Game: here are my nominations for the Fantastic Four: P.S. Sorry Joss, I m not your man ;)

16 August 2012

Scott Kitterman: Happy Birthday Debian

I ve been meaning to post this picture for a while. A few months ago I was at a local pottery/ceramics shop with my family. They were all decorating things and either my wife or one of my children suggested I do one too. Art it not my thing. I thought about it and finally an idea I ll make a Debian coffee mug. I used the browser on my phone to go to debian.org and then I blew the logo up to the full size of the screen and traced it onto paper. I used that as a template to paint it onto the largest coffee mug I could find. Here s the result. I hope you enjoy the picture (note the actual coffee stain for authenticity). Image

15 January 2012

Scott Kitterman: LEGO MINDSTORMS NXT 2.0 Support in Debian/Ubuntu

A LEGO MINDSTORMS NXT 2.0 recently arrived at our house. Of course it only comes with proprietary support for Windows/Mac, so I set out to see what FOSS support for the hardware I could find. I found nxt-python. It wasn t packaged, so I packaged it up and uploaded to Debian (from whence it came to Ubuntu). It s now in for the next release of both distributions (Wheezy/Precise). This is a bit different than the provided software (which compiles code, downloads it to the NXT, and then runs it untethered). For nxt-python the nxt needs to be connected to your computer via USB or bluetooth. It s a lot of fun and it s given me a chance to introduced our youngest child to the idea that there s more to computers than point and click. Currently user level access to the device doesn t work, it has to be accessed by root. Fixing that is on my TODO. I hope someone else out there has an NXT and enjoys this too. UPDATE: Added a udev rule and uploaded again, so anyone in plugdev can access the NXT brick.

6 October 2011

Scott Kitterman: python2.7 default python in wheezy

python 2.7.2-7 wheezy all
python 2.7.2-7 sid all This took a lot of work from a lot of people. Thank you everyone. Fortunately there won t be a python2.8, so we don t have to do this again.

14 March 2011

Scott Kitterman: DNS and Python

If you ve ever needed to care about DNS and Python, you probably know about pydns (python-dns) and dnspython (python-dnspython). Both have been around a long time (dnspython hit 1.0 in 2003 and the origins of pydns are long enough ago that they are lost to the mists of time I think dnslib.py, from which it is derived was initially developed with Python 1.5). They each have their advantages.
Until recently, if you needed DNS functionality and you re interested in Python 3, you were out of luck. Last month I had some business travel with long airplane rides that I put to good use and I ported pydns to Python 3. Upstream took the changes and released it as py3dns, so now you have a Python 3 DNS option. Packages are available in Debian Wheezy/Unstable and in Ubuntu Natty as python3-dns. It passes all the tests (better than the existing pydns), but I know test coverage is incomplete, so take it for a spin and let me know if there are problems. The code isn t pretty (it s set of minimal changes to get to a working Python 3 port), but it seems to work OK.

5 March 2011

Amaya Rodrigo: Indignez vous (II)

Spend millions visiting space TWICE, take Amazon referal money from non profit... priceless!

Take Amazon referal money from non profit... priceless!

From skitterman.wordpress.com/2011/03/02/business-oppor<wbr></wbr><wbr></wbr>tunity-in-ubuntu/#comment-364:
Mark, with his wealth, could have set up any model of organisation. He chose a for-profit one. As such, the conflict of loyalty necessarily must become ever more pronounced as that profit is sought.
Thanks to a former friend for pointing me to these two people who could express this better than me.

3 November 2010

Scott Kitterman: Liquor and Guessing

Those of us who work in technical areas like to believe that because we are engaging in technical endeavors rather than social endeavors, our work is defined and predictable. This hints that we know the future. I think Scott Adams captured the thought well:
We should not be so cocky. While the technical world is more structured and predictable than other areas, it has its limits too. One can only see so far down into complexity before predictability is lost in the detail. That s where we get so called Heisenbugs . Looking out to the future we can only see so far as well. Recently I ve been reading The Black Swan. It is a useful reminder that the future isn t as linear and predictable as we d like to pretend it is. One idea that has stuck in my head is the idea that in order to take something into account that one will know in the future in one s predictions, one must already know it. There is an inherent limit to how far we can see. How is this relevant to distribution developers? Each time we set off to develop a new release, we make an assessment of how to best expend the available resources (our own, our company s, our group of people we can talk into doing stuff) to make things better . We do the best we can, but we must always be mindful of the fact that we press forward using our best engineering judgement, but as we look into the future, eventually this is all just liquor and guessing too.

14 July 2010

Scott Kitterman: No, it s not a bug in my site

I maintain a Sender Policy Framework (SPF) record testing tool. If you happen to use it and it says your record isn t valid, your first action should not be to email me and ask if it s a bug in the tool. That is all.

21 June 2010

Scott Kitterman: Hello Planet Debian

This is the obligatory Hello world post. I m a developer both in Ubuntu and Debian. In Debian most of my work has been in the Python world where I co-maintain python-defaults and python3 defaults as well as several modules, extensions, and applications. I ve been contributing to Debian development for about 3 years now and recently became a DD.
Just so this post won t be completely free of technical content
Most of you will have heard that Python 2.6 is now the default in Sid. Once this transition is complete and migrated, the Python system that s planned for Squeeze will be in place (I know this is a topic that is very dear to some people, but I don t care to discuss the history of it in my blog and won t approve comments in that direction).
Of more technical interest, I think, is that the core system around Python 3 is starting to appear. The current version of Debian Python Policy begins to address Python 3 issues for the first time and we now have a supported and default Python 3. There is more work coming between now and freeze time to more completely define how the Debian Python 3 system should work. While many upstreams don t support Python 3 yet, we want to provide a solution that makes it easy for maintainers to provide Python 3 packages where they do.

1 June 2010

Debian News: New Debian Developers (May 2010)

The following developers got their Debian accounts in the last month: Congratulations!

20 December 2009

Stefano Zacchiroli: RC bugs of the week - week 15

RCBW - week #15 Here are last weektoday squashes, by yours truly: Some highlights:

24 May 2008

Ond&#345;ej &#268;ert&iacute;k: Ubuntu Developer Summit in Prague

Last weekend I was at FOSSCamp. Since I live in Prague I wanted to go to Ubuntu Developer Summit (UDS) each day, but unfortunately I had some exams, so I only went on Wednesday and Friday.

On Wednesday I first met Lars Wirzenius:


we agreed to go to pub in the evening. Then I did a little work, there was quite a nice view from the window (Prague castle on the horizon):



and I went to the #ubuntu-devel-summit IRC channel and pinged Scott Kitterman, whom I new from the Debian Python Modules Team (DPMT), but didn't know how he looks like. We met and once I knew Scott, it was easy to get around, so he introduced me to Steve Langasek (pronounced Lang ek). We agreed to go to pub as well. Steve lives in Portland, OR, where I spent the summer 2005 and Scott is from Baltimore where I spent the summer 2006.
Then I also met Riku Voipio, Martin B hm, Christian Reis (whom I asked if it's possible to support Debian unstable on Ubuntu Personal Package Archives and he said that it will probably happen, so that's really cool -- I also offered my help with this) and others, so in the end, there were 14 of us going to the pub, so I chose again the same pub as with the FOSSCamp people and it seems it tasted good again:




Notice the sv kov na smetan above, my favourite meal. Good choice Scott. :)





Ok, that was on Wednesday. On Friday I arrived at around 3pm, looked at the schedule table and noticed that Matthias Klose should be at UDS too, so I started IRC and pinged him. Fortunately, Emilio Pozuelo Monfort, whom I know from DPMT as well, replied first so we met, it was cool and he showed where Matthias is. I am very glad I met him, so we discussed python-central and python-support packages and why we have them both, also with Scott later on.

When I was waiting for Matthias, I sat next to Nicolas Valc rcel, started my laptop and begun looking at some SymPy bugs and Nicolas noticed that and said -- "You are developing SymPy?", I said "Yes.", flattered. And he showed me a bug with plotting and Compiz, so we immediately reported that to pyglet.

In the evening people continued to some kind of a party, but unfortunately, I was already going to some other pub.

Overall, even though I was there for only two afternoons, it was just awesome and I utterly enjoyed meeting all the people I knew from mailinglists and IRC.

30 July 2007

Reinhard Tartler: revu

Scott Kitterman ubuntu@kitterman.com writes:
Why do REVU and mentors need to be separate?
I’ve been thinking about this as well. Here my thoughts: I never actively used mentors. To me, mentors is mainly an apt-get’able repository, where interested contributors can submit packages. It acts mainly as a hosting service for packages. There are quite some differences to REVU, but I think the most important one is that REVU lets you collect opinions on a contribution in the web application. In mentors.debian,net, this happens on the mailing list. Do we need this disctinction? I don’t think so. See e.g. Bundle Buggy (http://bundlebuggy.aaronbentley.com/), which is used on the bazaar development mailing list to collect and review contributions. It has got a new feature which allows Developers to vote on a submission via email commands on the mailing list, to which Bundle Buggy is subscribed. I think that ideally, we could join all three mediums: Mail, Web-app and IRC. REVU could look for comments and commands for a package on a mailing list. On the other hand, reviews and submissions could be announced on an IRC Channel. We could even think about giving comments/commands via irc. It mainly needs one: Someone to do it. I’m sorry to say that REVU isn’t really under development since some time. I’d be more than happy if some people would approach me and said: “I want to implement some of the ideas floating around REVU2”. I think this would perhaps force me to start again coding on it. ATM, REVU is in maintenance only mode. :(

Next.

Previous.